Hm, das sieht interessant aus. Danke! Schön, das du den HttpGetter verwendet hast, damit hast du mich positiv überrascht. Ich sehe auch, dass du dieses Feature in den AC Charger in der Web UI unterbringst, was ich sonst verlangt hätte.

Allerdings hab ich natürlich, ganz meiner Art entsprechend, auch zu meckern:

• Coding Style, Einrückungen.
• Richtig wäre ja, wenn man auswählen kann: Huawei AC charger oder Shelly, korrekt? Oder ist das komplementär? Wenn es exklusiv sein sollte, dann müsste man eigentlich erstmal eine AC charger Abstraktion einführen, wie bei der Batterie auch, wo man dann auswählen kann, mit welchem "Provider" man hantieren will (Huawei AC charger oder "Shelly").
• Mir gefällt die Konkretisierung nicht. Was du eigentlich anbietest, ist ein Interface, um ein Ladegerät per HTTP zu steuern. Ob das ein Shelly ist, oder wie ich mir das wünschen würde, ein mit Tasmota ausgestatteter Shelly oder ein No-Name-Board mit Tasmota, oder was ganz anders, soll erstmal dahingestellt sein. Aber das können wir auch nachziehen, das muss nicht sofort sein. Aber verstehst du, was ich meine?

Code Style schaue ich mir an, dachte dass passt schon. Nehme hier gerne Tips an.

Es war Absicht beide Charger parallel zuzulassen. So kann man das Huawei Überschuss orientiert und on TOP noch via Shelly ein statisches Netzteil als Booster und um auch mehrere Phasen zu belasten. Bei meiner 25kwp Anlage aufm Dach komme ich regelmäßig über die 2500W vom Huawei. Werde auch evtl. das Huawai mit 75A testen... Wobei ich einphasig >16A eigentlich nicht so mag...

Das ganze dann noch Erweitern, dass man die URIs zum senden und JSON Werte zum auslesen spezifizieren kann, liefere ich gerne in einem späteren Update...

Ich fände eine mehrstufige Regelung auch super interessant.

So könnte man ggf. auch einfache kleinere Verbraucher kaskadiert starten und stoppen. ZB heizstäbe, Pumpen, Wärmepumpen,….

Hm, das sieht interessant aus. Danke! Schön, das du den HttpGetter verwendet hast, damit hast du mich positiv überrascht. Ich sehe auch, dass du dieses Feature in den AC Charger in der Web UI unterbringst, was ich sonst verlangt hätte.
Allerdings hab ich natürlich, ganz meiner Art entsprechend, auch zu meckern:

• Coding Style, Einrückungen.
• Richtig wäre ja, wenn man auswählen kann: Huawei AC charger oder Shelly, korrekt? Oder ist das komplementär? Wenn es exklusiv sein sollte, dann müsste man eigentlich erstmal eine AC charger Abstraktion einführen, wie bei der Batterie auch, wo man dann auswählen kann, mit welchem "Provider" man hantieren will (Huawei AC charger oder "Shelly").
• Mir gefällt die Konkretisierung nicht. Was du eigentlich anbietest, ist ein Interface, um ein Ladegerät per HTTP zu steuern. Ob das ein Shelly ist, oder wie ich mir das wünschen würde, ein mit Tasmota ausgestatteter Shelly oder ein No-Name-Board mit Tasmota, oder was ganz anders, soll erstmal dahingestellt sein. Aber das können wir auch nachziehen, das muss nicht sofort sein. Aber verstehst du, was ich meine?

kannst du mir einen Tipp geben, wie ich deine AC-Charger Admin Änderungen in meinen Fork gemerged bekomme. wir haben nun jetzt ja beide die gleichen Files geändert....

Ok habs gefunden...

Bitte um review

Danke @Snoopy-HSS für Deinen PR!

Das Review sollte @schlimmchen / hoylabs machen. Vielleicht abstrahiert er den PR auch so, wie er sich das vorstellt und es mit dem Dynamic Power Limit zusammen passt ?

Richtig wäre ja, wenn man auswählen kann: Huawei AC charger oder Shelly, korrekt? Oder ist das komplementär? Wenn es exklusiv sein sollte, dann müsste man eigentlich erstmal eine AC charger Abstraktion einführen, wie bei der Batterie auch, wo man dann auswählen kann, mit welchem "Provider" man hantieren will (Huawei AC charger oder "Shelly").

Die Idee einer AC Charger Abstraktion macht aus meiner Sicht auf jeden Fall Sinn. Schon alleine weil man ja mehrere dieser Geräte auf der gleichen / unterschiedlichen Phasen haben kann. Siehe die Beispiele von @spcqike

Ich fände eine mehrstufige Regelung auch super interessant.
So könnte man ggf. auch einfache kleinere Verbraucher kaskadiert starten und stoppen. ZB heizstäbe, Pumpen, Wärmepumpen,….

Dafür bräuchte man dann eine Prio-Liste pro Phase. Evtl noch einen Zeitplan für die Wochentage und/oder eine (temperatur-abhängige) Sommer-/Winterumschaltung.

Oder eine vorwählbare Dauer zB von 3 Stunden für die Waschmaschine / den Trockner ?

Dann sind wir aber schon bei OpenDTU-OnWärmePumpe oder OpenDTU-OnXYZ

Mir gefällt die Konkretisierung nicht. Was du eigentlich anbietest, ist ein Interface, um ein Ladegerät per HTTP zu steuern. Ob das ein Shelly ist, oder wie ich mir das wünschen würde, ein mit Tasmota ausgestatteter Shelly oder ein No-Name-Board mit Tasmota, oder was ganz anders, soll erstmal dahingestellt sein. Aber das können wir auch nachziehen, das muss nicht sofort sein. Aber verstehst du, was ich meine?

Das ganze dann noch Erweitern, dass man die URIs zum senden und JSON Werte zum auslesen spezifizieren kann, liefere ich gerne in einem späteren Update...

Das wäre auch mein einziger Kritikpunkt gewesen, aktuell wird nur ein ausgesprochen flexibler Shelly Plug S unterstützt.
Viele andere Shelly’s haben auch einen Schalt-/Relaisausgang: Shelly Plus 1 PM, Shelly Pro 3EM, etc. bei denen sich die URLs jeweils unterscheiden.

Aber vor allem wie sieht es mit OpenSource/Hardware wie Tasmota/Sonoff Geräten bzw closed Source Tuya aus ?

closed Source Tuya

kann man, und würde ich immer, per localtuya local mit MQTT ansprechen.
Kann man Tuyageräte per HTTP requests steuern?

Unterstützung aller per http Request Steuerbaren devices reiche ich nach...

OPENdtu-Hausautomation wird es sicherlich nicht werden...

<offtopic>

closed Source Tuya

kann man, und würde ich immer, per localtuya local mit MQTT ansprechen. Kann man Tuyageräte per HTTP requests steuern?

Ich hatte irgendwann mal das Tasmota Unterprojekt Tuya-Convert gesehen aber noch nicht ausprobiert.
https://tasmota.github.io/docs/Tuya-Convert/

Und es sollte m.W. auch ein SDK für die Tuya Chips / MCUs von Beken BK7231T MCU geben.
Nur das Flashen ist immer ein bisschen aufwendig, weil man die Steckergeräte eben aufbekommen muß.
Siehe https://github.com/FlorianSoler/OpenBeken-Action-lsc-smartplug-with-monitoring-guide
</offtopic>

@schlimmchen
Moin,

Bei mir scheint das Configuration Guard Problem zuzuschlagen.
Der ESP hängt sich auf.

Hast du TIPS wir ich das wieder hinbekomme.
Rufe eine Funktion aus dem Loop auf, was die Configuration schreibt. ShellyACPlug.cpp PowerON z.b.

Merci

HSS

Bei mir scheint das Configuration Guard Problem zuzuschlagen.

Das ist völlig richtig.

Ich erkenne den Grund nicht, warum es nötig ist, dort im config struct zu hantieren. Warum müssen diese Booleans in der Config persistiert werden? Mein Eindruck ist, dass das ohnehin gerade gezogen werden muss um nicht exzessiv den Flash zu beschreiben. Kannst du diese Variablen nicht über private Klassenvariablen in ShellyACPlugClass implementieren?

Bei mir scheint das Configuration Guard Problem zuzuschlagen.

Das ist völlig richtig.

Ich erkenne den Grund nicht, warum es nötig ist, dort im config struct zu hantieren. Warum müssen diese Booleans in der Config persistiert werden? Mein Eindruck ist, dass das ohnehin gerade gezogen werden muss um nicht exzessiv den Flash zu beschreiben. Kannst du diese Variablen nicht über private Klassenvariablen in ShellyACPlugClass implementieren?

Recht hast du.
Spart auch ne Handvoll Code zeilen.
Ist umgesetzt, gerne REVIEW

Generalisierung eingebaut.
URi können konfiguriert werden.
@schlimmchen Bitte um review...

Erstmal danke für deinen weiteren Einsatz!

Wenn ich das richtig sehe, kann man den Huawei AC Charger und diese Smart Plug unabhängig voneinander und gleichzeitig benutzen. Ist das ein (wichtiges) Feature? Ich sah bisher diesen Smart Plug als alternative zum Huawei AC Charger, also dass man nur eins von beiden verwendet, um den Akku zu laden. Ähnlich wie man nur einen Typ PowerMeter verwendet und nur einen Typ Batterie?

Ich finde das Feature immer noch gut, auch wenn es schon zwei Monate liegen bleiben musste. Allerdings bin ich mit der Abstraktion noch nicht so ganz froh. Ich tendiere dazu, das Feature zu übernehmen, aber einzuplanen, es anders in den Code einzufügen vor dem Release, in dem es dann "öffentlich" wird -- also vermutlich dem übernächsten Release Mitte Januar oder so in etwa.

Jedenfalls bin ich jetzt auch Huawei-Netzteil-Eigentümer und befasse mich mit diesem letzten für mich unerkundeten Fleck in OpenDTU-OnBattery, und da fügt sich dieses Feature dann sehr gut ein.

Es ist kein Must have, das beide unabhängig arbeiten.
Aber da man ja mit Huawei auf 2,5 KW begrenzt ist und die Verteilung auf mehrere Phasen/Zuleitungen von Vorteil ist, habe ich es parallel und nicht ausschließlich aufgebaut.

Nimm es gerne als Grundlage und füge es da ein, wo es am besten passt.

Solltest du Unterstützung brauchen, sag einfach bescheid.

Evtl. kann man es ja noch um 2-N Stecker erweitern.
Ein 1000w 24V/48V/72V/96V Charger kostet ja weit unter 100€ und ich lade lieber 3x1000 als 1x 3000W, schon alleine wegen den Strömen auf der AC wie auch DC Seite. Ebenso ist ein einfach DC Charger leichter zu handhaben als das Huawei Teil.

Ein 1000w 24V/48V/72V/96V Charger kostet ja weit unter 100€

Hast du da mal eine Modellempfehlung mit 48v für mich?

Ein 1000w 24V/48V/72V/96V Charger kostet ja weit unter 100€

Hast du da mal eine Modellempfehlung mit 48v für mich?

Welche Ladeschlussspannung?

Welche Ladeschlussspannung?

Ich teste gerade noch ein wenig mit den Werten, aber ich denke so 49v - 56v+/-
Also 52v, nicht 48v 😄

https://de.aliexpress.com/item/1005007554940159.html

Okay danke dir 👍